Валидатор это – Валидация что это простыми словами, кто такой валидатор

Содержание

Валидатор (устройство) — это… Что такое Валидатор (устройство)?

У этого термина существуют и другие значения, см. Валидатор.

Валида́тор (от англ. valid — действительный, имеющий силу, правомерный) — электронное или механическо-электронное устройство, предназначенное для отображения и/или проверки информации документов (проездных билетов общественного транспорта, пропусков) записанных на бесконтактные или контактные электронные носители для оперативного контроля за правомерностью прохода пассажира в салон автобуса, троллейбуса, трамвая и иных подобных видов наземного транспорта, на посадочную платформу в метро, на железной дороге и других видах транспорта, где контроль оплаты проезда осуществляется за пределами транспортного средства, или сотрудника в офис. Часто совмещён c турникетом.

Преимуществом валидатора служит высокая степень учёта пассажиропотока на транспорте, возможность точного контроля над посещением закрытых офисов и предприятия и сравнительно недорогая цена обслуживания устройства.

Валидаторы на транспорте

Московское метро

Московский наземный транспорт

Первые турникеты с валидаторами в наземном общественном транспорте Москвы в рамках эксперимента по внедрению автоматизированной системы контроля проезда (АСКП) появились в 2001 году в Зеленоградском административном округе на автобусном маршруте № 16^[1]. К середине 2002 года система была распространена на все зеленоградские автобусные маршруты (муниципального подчинения), а с сентября 2007 года и на весь наземный городской общественный транспорт муниципального подчинения.

Правительство Москвы мотивировало решение об установке устройств большим количеством безбилетных пассажиров, ездящим по поддельным документам.

Несмотря на то что с помощью электронной системы проверки оплаты проезда существенно сократилось число безбилетных пассажиров, многие жители Москвы отрицательно восприняли нововведение. Так, из-за автоматов посадка стала занимать больше времени: если до введения устройства посадка и высадка обычно занимала не более одной минуты, то после при большом количестве пассажиров она стала занимать 3-4 минуты. Это естественным образом отразилось на времени следования по маршруту, в некоторых случаях весьма существенно. В конце декабря 2009 года Мосгортранс вывел на улицы Москвы новые комфортабельные маршрутные такси. Первые 100 машин вышли на маршруты 1−го, 3−го, 10−го и 16−го автобусных парков и Филевского автобусно-троллейбусного парка, которые оборудованы валидаторами, турникеты в машинах отсутствуют. Введение новый муниципальных машин либо сократит количество частных маршруток, либо будет способствовать повышению качества услуг, которые предоставляют коммерческие перевозчики

[2].

Санкт-Петербург

Ручной валидатор ПК-001

С января 2007 года на большинстве социальных маршрутов общественного транспорта города у кондукторов появилось устройство для считывания информации с проездных документов — валидатор. Позже валидаторы появились у водителей маршрутов, которые не имеют кондукторов.

К 2011 году большая часть городских автобусов была переведена на новую систему электронного контроля оплаты проезда (СЭКОП). Данная система предусматривает наличие стационарных валидаторов в салоне транспорта на поручнях (от 4 до 8 штук), которые позволяют пассажиру самостоятельно производить оплату проезда (валидацию электронного проездного билета).

[3]^[4]^[5]^[6]

В состав СЭКОП входят валидаторы двух типов простые и информационные. Простые валидаторы имеют светодиодную индикацию, которая информирует пассажира о следующих событиях:

Валидатор готов к считыванию электронного проездного билета.
Проезд оплачен.
Проезд не оплачен (например истек срок действия).
Электронный проездной билет приложен повторно (проезд на данном маршруте уже оплачен).
Валидатор заблокирован контролёром на время проверки оплаты проезда.

Индикация работы валидатора

Информационные валидаторы имеют ЖК дисплей, который, помимо индикации событий аналогичных простому валидатору, может выводить информацию об электронном проездном билете (срок действия, ресурс поездок или баланс в зависимости от типа ЭПБ). Для получения такой информации, необходимо сначала оплатить проезд, затем снова приложить билет к информационному валидатору. Валидатор покажет что билет приложен повторно, и через некоторое время отобразит информацию о ресурсе ЭПБ.

Другие города

В Красноярске с помощью пластиковой электронный карты льготные группы населения могут расплатиться за проезд в городском общественном транспорте с начала 2008 года, все остальные граждане — с ноября 2010 года^[7]^[8]^[9]. Кондукторы всех автобусов, троллейбусов, трамваев имеют переносные ридеры (валидаторы). Пополнить карты можно через многофункциональные платёжные терминалы, а также в городских отделениях почтовой связи.

В Кемерово оплатить проезд подобным образом можно с января 2010 года. Система введена во всех автобусах, троллейбусах и трамваях города. При оплате при помощи транспортной карты возможна экономия до 1 руб на одну поездку.

В городе Алма-Ата (Казахстан) с января 2008 года система оплаты проезда через валидатор с помощью электронной карты или наличными действует во всех трамваях и троллейбусах города. В автобусах данная система не получила распространение, на многих автобусах валидаторы были установлены, но не действуют. В 2011 году действующие валидаторы были введены на нескольких автобусных маршрутах и принимают только железные деньги, так как система считывания купюр и пункты пополнения магнитных карт системы eCash не функционируют, а зачастую и отсутствуют вовсе.

В Екатеринбурге с конца 2009 года введена транспортная карта «Е-карта». Система введена во всех троллейбусах, трамваях и автобусах города. Валидаторы находятся у кондукторов либо установлены на вертикальном поручне на задней площадке. Также валидаторами оснащены и некоторые из маршрутных такси. Возможна оплата проезда и обычным способом. с 2012г. оператор МегаФон запустил услугу по оплате проезда с мобильного телефона в городском транспорте Екатеринбурга. Правда, сначала такой сервис был реализован лишь в Екатеринбургском метро, но теперь такая возможность появилась и в наземном транспорте. Благодаря новой услуге МегаФона, оплачивать проезд с мобильного телефона можно во всех видах наземного общественного транспорта Екатеринбурга, на ряде коммерческих маршрутов, а также на всех станциях Екатеринбургского метрополитена — везде, где принимается «Е-карта».

В Ярославле с 2010 года во всех видах общественного транспорта введена система оплаты при помощи пополняемого электронного проездного(оплата производится на месяц вперёд). Валидаторы предоставлены кондукторам и водителям. Также осталась возможность приобретения обычных билетов разовой поездки.

Примечания

Ссылки

МФ Тариф

dic.academic.ru

Валидация сайта

Сегодняшнюю статью я хочу посвятить валидации сайта (то есть HTML). Сперва определим что означает этот термин! Валидация сайта — это проверка синтаксических ошибок, проверка вложенности тэгов и другие критерии. Как правило, валидаторы (сервисы для проверки сайтов на наличие ошибок в структуре документа) проверяют HTML-код на соответствие определенному стандарту, который указан в самом начале любой HTML-страницы первой строчкой. Если вы не знали для чего она, теперь будете знать! 🙂 Но для чего, собственно, нужна эта самая валидация и на что она влияет?

«Что такое валидация сайта?»

Как я уже говорил выше, валидация — это соответствие HTML-кода определенным правилам и стандартам. На смену XHTML пришла технология HTML5, которая значительно облегчила жизнь разработчикам. Дело в том, что в версии XHTML синтаксис был очень строгим. Если в HTML5 вы можете писать тэг переноса <br> как без наклонной черты, так в таком виде <br />, то в XHTML будет верным только последний вариант. HTML5 не так строг, да и к тому же появилось множество полезных тегов, но не об этом сейчас 🙂 .

«На что влияет валидация сайта?»

А сейчас ответим на второй вопрос.

Валидация сайта позволяет следить за правильным отображением сайта в разных браузерах. Например, если не закрыть тэг или где-то сделать опечатку в коде, в дальнейшем одна и та же страница может отображаться в разных браузерах по-разному. Также стили для сайта (CSS) могут отображаться не так как вы этого ожидали. Поэтому необходимо внимательно следить за этим.

Также я не мог не сказать что валидация влияет на поисковые системы: поисковые системы отдают предпочтение сайтам с валидным HTML-кодом. Имейте это в виду!

Ну что, я вас убедил в том, что валидация сайта действительно необходима? Тогда с теорией закончили и переходим к практике!

Способы проверки валидации

О каждом из способов я написал подробные инструкции в виде текста, а также, если кому-то лень читать и вникать, снял видео 😉 .

1 способ. Сервис validator.w3.org

Суть первого способа состоит в использовании сервиса для проверки валидности сайта. Как проверить валидность сайта с помощью сервиса validator.w3.org:

1. Переходим по адресу: validator.w3.org. Перед нами откроется страница, на которой есть 3 вкладки. На первой вкладке «Validate by URI» вы можете проверить валидность сайта размещенного в интернет, на второй «Validate by File Upload» — загрузить файл с компьютера, и на третьей «Validate by Direct Input» — вставить содержимое файла непосредственно в форму для ввода. Я буду рассказывать о первом варианте, то есть когда сайт размещен в интернет (думаю и с другими способами у вас проблем не возникнет). Поэтому выбираем первую вкладку как на изображении ниже:

2. Далее нажимаем на кнопку «More options» и здесь необходимо выставить следующие значения:

Character Encoding — кодировку вашего сайта. НО! Если она уже есть между тегами <head> (у себя на сайте в браузере нажимаете на сочетание клавиш CTRL+U, и ищете в начале документа примерно такую строку
1
<meta charset="UTF-8" />
), то здесь оставляем выбранным
(detect automatically).
Document Type — тип текущего документа. Он указывается первой строкой в HTML (когда находитесь на своем сайте, в браузере нажимаете сочетание клавиш CTRL+U, и смотрите самую первую строчку
). Если же в первой строчке присутствует что-то похожее, тогда и здесь оставляйте значение (detect automatically).

Если у вас что-то из того, что я описал выше нету, тогда вам самостоятельно необходимо будет выставить эти значения. Я здесь ничего не менял и оставил всё как есть.

3. Затем в поле «Address» вводим адрес вашего сайта как сделал я:

После чего нажимаем на кнопку «Check», которая расположена по середине серого блока:

4. Далее идет валидация вашего сайта и через некоторое время появится результат валидации. Будет похожая страница с сообщением «This document was successfully checked as HTML5!» (что значит что ваш сайт успешно прошел проверку на валидность определенному типу документа, то есть в моем случае HTML5):

Если у вас надпись на красном фоне — это значит что у вас присутствуют ошибки в вашем HTML-документе. Их необходимо исправить. Для этого просто выделяете название ошибки (в видео я всё это показываю как делать) и вставляете ее, например, в Google. Далее просто читаете как с этой ошибкой боролись другие веб-мастера и исправляете ее следуя этим советам. Также у вас есть другой выход — поручить это дело знающему человеку, который разбирается в коде, и пусть он это сделает за вас.

Для тех, кто не понял или поленился почитать — смотрите видео ниже 🙂

2 способ. Плагины для браузеров

1. Плагин для браузера Mozilla Firefox — Перейти

Переходите по ссылке выше, выбираете версию браузера Firefox и нажимаете на кнопку «Download». Затем выбираете необходимую операционную систему и устанавливаете как обычное дополнение. (те, кто не понял, смотрите видео 🙂 )

2. Плагин для браузера Google Chrome — Перейти

Здесь вам необходимо нажать на кнопку «Бесплатно» и затем во всплывающем окошке нажать «Добавить».

3. Плагин для браузера Opera — Перейти

Здесь также происходит обычная установка дополнения.

4. Плагин для браузера Safari — Перейти

Установка:

Распакуйте архив с плагином.
Скопируйте файл «Safari Validator.webplugin» в папку, где установлен браузер, затем /Library/Internet Plug-Ins (создайте папку, если она отсутствует)
Сделайте двойной клик на файле Safari Validator.safariextz.
Перезапустить браузер Safari.

Как установить плагин в Firefox и как пользоваться им я рассказываю во втором видео:

Вывод

Вот и вся статья. Надеюсь видеоматериалы, а также текстовая информация, которую я здесь представил поможет вам улучшить ваш сайт и сделать его еще более «привлекательным» для поисковых систем 🙂 , ведь мы все так к этому стремимся. Если возникают вопросы и сложности на каком-либо этапе — пишите в комментариях, будем вместе разбираться! Тот, кто дочитал до конца статью и проделал всё, о чем я писал — уже улучшил свой сайт и результат не заставит себя ждать. 🙂

Успехов!

С Уважением, Юрий Немец

Валидация сайта или правильный HTML 3.75/5 (75.00%) 20 голос(ов)

sitehere.ru

Валидация: что это простыми словами

Довольно часто, когда речь заходит о стандартах выполнения и соответствия продукции требованиям, установленным в документации, встречается понятие валидации. Непосвященному в тонкости дела читателю, возможно, будет не до конца ясно, а что же оно значит. Ситуацию осложняет тот факт, что слова «валидация» и «верификация» часто путают между собой. Эти понятия всё чаще мелькают на различных сайтах во время регистрации или оплате покупки. Поэтому очень важно отделить зёрна от плевел и понять, что оба эти термина значат и в каких случаях каждый из них должен использоваться.

Вообще перевод английских технических терминов и их использование в русском языке сопровождается сложностями понятийного характера. Термины «валидация» и «верификация» появились в русском техническом языке с появлением технологического стандарта ИСО 9000. Основываясь на этом документе, некоторое время спустя был разработан его российский аналог – ГОСТ Р ИСО 9000-2008. Оба эти документа регламентируют терминологическое использование и обозначают основные понятия технического словаря. В том числе там можно найти и разъяснение значения интересующих нас терминов.

Что такое валидация и чем она отличается от верификации

Говоря простыми словами, валидация – это проверка продукции на то, насколько она соответствует заявленным характеристикам. То есть, какой-нибудь мобильный телефон не пройдет валидацию до тех пор, пока заказчики не удостоверятся, что в нём именно такая камера и именно такой объем памяти, за который они готовы были заплатить.

Верификация же – это именно процесс, предшествующий валидации продукции. То есть, когда заказчик телефона из предыдущего примера проверял его на соответствие заявленным требованиям, то он проводил верификацию мобильного телефона. Заодно в процесс верификации продукции обычно включается анализ изделия: все ли необходимые части на месте, правильно ли они работают и так далее.

А теперь ещё раз, но уже в сравнении. Валидация – это анализ продукции на её работоспособность (включается ли телефон и может ли он звонить). Верификация – бюрократический вариант, то есть в течение этого процесса тестеры сверяются, соответствуют ли составные части продукции установленным техническим стандартам изготовления.

Возможно, профессионалы в области стандартизации скажут, что это слишком грубое и неполное объяснение, но оно даёт общую картину того, что же это за слова такие непонятные.

Приведём еще один пример. Представим, что планируется выход на рынок нового напитка. Способ изготовления и необходимые стандарты отправляются на фабрику. Изготовитель по окончанию процесса производства проверяет (верифицирует) состав напитка и его соответствие заявленному стандарту. Заказчик партии напитков проводит серию тестов на то, насколько напиток нравится потенциальным покупателям по вкусовым качествам. Если на этом этапе проверки тоже не возникает никаких проблем, то напиток можно считать валидированным.

То есть, в процессе валидации проверяется, имеет ли изготовленная продукция тот результат, на который производители и разработчики рассчитывали во время его проектирования. Бывает, что продукция проходит процесс верификации, но на деле оказывается, что она не работает. Таким образом, валидированный продукт внушает большее доверие.

Использование валидации и верификации в онлайн сервисах

Частенько при регистрации на сайтах, не желающих плодить у себя фейковые странички, новым пользователям требуется пройти процесс верификации. Заключается он в получении СМС-уведомления или письма на электронную почту с кодом, который затем нужно будет ввести, дабы подтвердить, что вы на самом деле настоящий человек, а не бот.

Различные платежные системы тоже выдвигают такие требования к своим пользователям. Чаще всего новые пользователи не имеют доступа к полному функционалу, пока не пришлют свои паспортные данные и не подтвердят свой номер телефона. После подтверждения реальности вашей личности, ваш аккаунт считается валидированным и теперь пользоваться услугами сайта можно в полной мере.

В данном случае, если использовать метод подборки синонимов, то первый вариант верификации – это проверка, а вот валидация – это подтверждение, аттестация.

Хочется верить, что данная статья дала вам примерное понимание того, что представляет собой такой зверь, как валидация, и чем он отличается от своего сородича верификации. Не путайте эти два термина, ведь чистота и правильность вашего языка – это залог понимания слов другими людьми.

requesto.ru

Что такое валидатор микроразметки для Гугл и Яндекс и как им пользоваться

Тематический трафик – альтернативный подход в продвижении бизнеса

Мы выпустили новую книгу «Контент-маркетинг в социальных сетях: Как засесть в голову подписчиков и влюбить их в свой бренд».

Подпишись на рассылку и получи книгу в подарок!

Валидатор микроразметки — программное обеспечение, которое проверяет разметки веб-страниц в любых форматах и на всех существующих языках программирования.

Больше видео на нашем канале — изучайте интернет-маркетинг с SEMANTICA
Все любят путешествовать, особенно в гипермаркетах. Вот и ты, не нарушая общепринятых тенденций, отправляешься в поход по магазинам. Тебе нужно найти соки, воду, печенье, хлеб, носки, памперсы и другие вещи. Но магазин слишком большой, и для того чтобы обойти его, и найти то что нужно, может потребоваться не один час. Как вариант — обратиться к сотруднику гипермаркета, но покупок много, поэтому этот метод не всегда применим. Намного удобнее ориентироваться по вывескам, которые расположены между рядами, и точно указывают на размещение продукции в отделе.
Для того, чтобы подобрать актуальную и полезную информацию, поисковые боты также используют определенные алгоритмы подбора информации для пользователей.
Какая разметка считается правильной
Правильной семантической микроразметкой, считается та, которую хорошо воспринимает такие поисковые системы, как Google, Яндекс,Bing и Yahoo. Все мы не раз сталкивались с тем, что эти сервисы абсолютно по-разному индексируют информацию, поэтому чаще всего обращаем внимание на продуманные, броские и четкие сниппеты.
Поэтому, перед тем, как внедрить микроразметку на сайт, нужно определить тип ваших данных. Например, в карточке товара для интернет-магазина, необходимо разметить цену товара, его наименование, описание, изображение, отзывы, рейтинг. Так поисковый бот без каких-либо проблем сможет понять, что именно размещено на странице и сделает ее более релевантной.
Для проверки правильности микроразметки существует несколько сервисов:
инструмент проверки данных от Google;
валидатор микроразметки от Yandex;
validator.w3.org;
validator.nu.
Если ваша страница прошла валидацию на одном сервисе, то из-за различий в алгоритмах поиска, она может быть не пропущена на другом. Для того, чтобы поисковые роботы правильно проиндексировали разметку, разберитесь в ее структуре и настройках.
Зачем нужен валидатор разметки
Микроформаты – это стандарт семантической разметки, разработанный специально для структурирования информации на странице для программ-обработчиков. В нашем случае микроформаты позволяют указать поисковому роботу на смысловое значение отдельных фрагментов страницы и используются для передачи сведений об организации, товарах, отзывах, рецептах.
Любая страница в интернете состоит из HTML тегов, которые сообщают браузеру, каким образом будет отображаться та или иная информация, а микроразметка устанавливает поисковикам определенные рамки, в пределах которых и нужно искать. Поэтому она позволяет добиться лучшей релевантности страницы для поисковых роботов и пользователей. И самое важное — семантическая микроразметка позволяет улучшить внешний вид сайта в результатах поиска (snippet).
Сниппет без разметки:

Сниппет с разметкой:

Валидатор проверяет правильность всего процесса и определяет ошибки допущенные при работе с кодом. Ведь, если его как следует не проверить, это может негативно отразиться на индексировании ресурса и, тем более, на ваших доходах. Поэтому он является обязательным инструментом любого программиста или веб-мастера.
Страницы без ошибок в коде — мечта владельца любого сайт, так как результаты качественной работы явно отразятся на ваших позициях в поисковой выдаче. На сайте с 30+ позиции это никак не скажется. Однако когда поисковик показывает 15 место, а не 3 как хотелось бы, это означает серьёзные недоработки, которые влекут материальные затраты.
Чаще всего пользователи, которые начинают использовать такое программное обеспечение, неточно понимают как микроразметка сайта влияет на ранжирование. Яндекс отвечает, что оно действует только косвенно, при этом сайт становится более привлекательным для пользователя, его аудитория становится больше, в результате чего повысятся и его позиции. Он уточняет — не стоит ожидать результатов в ближайшие дни, так как они появятся только в течение одного-двух месяцев.
Как работает валидатор разметки
Для проверки страницы нужно ввести URL проверяемого документа или вставить нужный код в форме ниже.
В колонке «Результаты проверки» программа выведет распознанные недочеты и их расположение.
Существует два случая, когда выводится сообщение об ошибке:
если валидатор не может распознать разметку;
если у разметки нет соответствия стандарту, и она не может распознаваться корректно.
Сообщение о том, что «страница не обнаружена» означает несуществующую страницу. Возможно страница недоступна для поисковика по причине ошибки сервиса, или из-за ограничений безопасности.
При этом будет приведен перечень обязательных полей, которые не учтены в работе, отправленной для проверки.
Инструмент Google
Гугл в сотрудничестве с Yahoo! и Bing впервые в 2011 опробовали свое изобретение — валидатор микроразметки schema org, к которому позже примкнул и Яндекс. В результате валидатором стал пользоваться весь мир. Валидатор постоянно дорабатывается, а его функционал расширяется.
Как проверить:
1. С помощью URL-адреса. Подходит для владельцев активных сайтов. Копируете ссылку и вставляете в специально отведенное для нее поле.
2. При помощи HTML фрагмента. Этот вариант подойдет тем, кто только создает сайт и хранит его где-нибудь на локальном сервере. Действия те же — копируете код и вставляете для проверки.
Поддерживаемые форматы разметки у Гугл:
микроданные;
микроформаты;
RDF.
Поддерживаемые типы информации для разметки:
отзывы;
товары;
компании;
организации;
мероприятия;
музыка.
Инструмент Яндекс
За последние четыре года, программисты все чаще стали использовать семантическую микроразметку — размечены около 15% страниц рунета. Поэтому возросла потребность в валидаторах. И Яндекс не стоит в стороне от новых разработок в этой отрасли. Он, в отличие от Google, развивается более стремительно и создает новые универсальные инструменты.
Поддерживаемые форматы:
микроформаты;
Schema;
HTML;
RDF;
Open Graph.
Типы данных, поддерживаемые валидатором Яндекса:
товары;
цены;
адреса;
организации;
статьи;
музыка;
тест-драйвы;
рисунки;
видеоклипы;
рецепты;
фильмы.
Валидатор микроразметки позволяет проверить правильность структурирования данных. Он упрощает работу оптимизаторов и помогает правильно разметить контент на сайте. Это делает красивой информацию о странице в поисковой выдаче и привлекает посетителей на ресурс.
semantica.in
Валидация контента сайта по W3C
Что такое валидация html кода?
Html, как известно, язык разметки, который является основой для подавляющего большинства страниц в интернете. Как у любого другого языка, у html есть правила написания — синтаксис. Валидный html-код это код, который соответствует всем рекомендациям написания кода — спецификации.
Спецификации. Что это?
Как у любого другого языка, у HTML существуют свои правила написания — синтаксис. Эти правила пишет команда профессионалов, заинтересованных в развитии html и занимающихся разработкой новых элементов, отвечающих параметрам современных устройств, актуальных современным технологиям и, самое главное, отвечающих современным требованиям безопасности. Именно правила написания элементов html, установленные разработчиками языка, называются спецификацией.
После разработки основной части нового релиза html, разработчики языка выкладывают спецификацию к нему в публичный доступ на обсуждение всех желающих вебмастеров мира, внимательно читают комментарии и, если потребуется, вносят правки. После завершения всеобщего обсуждения, новый релиз языка выходит в мир и им можно пользоваться.
Каждый документ, использующий html код, должен следовать правилам языка. Последняя опубликованная версия HTML — пятая и стала относительно сложная, так что вебмастера, не прочитавшие последнюю версию спецификации, легко могут сделать ошибки в коде.
Cколько спецификаций существует.
Начиная с HTML5, разработчики и производители браузеров могут выбирать между двумя разновидностями одного и того же языка разметки: спецификациями, разработанными консорциумом W3C, и тех, что разработаны WHATWG.
В принципе эти спецификации очень похожи, однако, с годами, между ними все больше и больше отличий. Большинству вебмастеров не стоит сильно беспокоиться по этому поводу: или эти отличия спецификаций не скажутся на их проектах, или разработчики браузеров будут поддерживать оба стандарта языка.
Однако при использовании в своих проектах только что появившихся нововведениях в одной из спецификаций, у вебмастеров могут возникнуть проблемы. Например Дэвид Бэрон из Mozilla заявил:
Если HTML-спецификации W3C и WHATWG различаются, то мы стараемся следовать спецификации WHATWG.
Зачем нужна валидация?
Поисковые роботы сканируют страницы вашего сайта для поиска релевантного контента. Поисковые роботы подчиняются стандартам HTML. Если в вашем HTML коде есть грубые ошибки, то роботы могут запутаться и не найти контенте на вашей странице. Не закрытый тег или кривая верстка сильно ударят по изучению вашего сайте роботами. Наличие битых ссылок существенно замедлит индексацию вашего ресурса. Валидный код в разы упрощает индексацию страниц вашего сайта и позволяет им быстрее оказаться в выдаче.
Разбор ошибок на примере главной страницы сайта Клондайка.
В данной части статьи разберем валидацию html5 по спецификации W3C на примере главной страницы сайта студии Клондайк.
Как проверить HTML код на валидность? Для проверки валидации нашего HTML5 кода используем известный HTML Validator для проверки соответствия кода w3c стандартам. Не смотря на то, что не все HTML ошибки приведут к проблемам поискового ранжирования, некоторые из них могут затруднить поисковым системам успешно индексировать страницы и могут испортить все ваши SEO усилия.
Переходим на сайт валидатора от W3C , выбираем вкладку «Validate by URL», в поле «Address» вставляем адрес проверяемого сайта и жмем кнопку «Check».

Через пару секунд получаем результат проверки.

В нашем случае было обнаружено 36 ошибок.
Рассмотрим каждую ошибку по отдельности.
Как мы сразу видим, валидатор показывает что на нашей главной странице присутствует сразу 24 однотипных ошибки — у нас не проставлен атрибут alt у картинок.

Смотрим исходный код сайта:

Действительно, у картинок не прописан атрибут alt.
Зачем нужен этот атрибут? Когда загружается страница, вначале загружается текст из атрибута alt, а уже после идёт смена текста на изображение. Если в браузере отключена загрузка изображений, то на месте изображения будет альтернативный текст (из атрибута alt).
Что ж, приступим к исправлению. Для каждой картинки мы пропишем соответствующий ей атрибут alt.
Далее убираем лишний закрывающий тег </section>
Валидатор показывает нам, что на проверяемой странице сразу в 4 местах использован устаревший тег nobr.

Этот тег использован у слов которые пишутся через дефис. По правилам русского языка, такие слова не следует разрывать переносом на другую строку, если слово целиком не умещается на предыдущей строке. На мобильных устройствах очень большая вероятность что такие слова будут перенесены из-за небольших размеров экранов. Поэтому, ради соответствия правилам русского языка и грамотного отображения контента, мы пожертвуем 100% валидацией и оставим тег <nobr> в коде страницы.
Переходим к следующей ошибке
Смотрим исходный код и находим искомое место:
<input type="submit" value="OK" name="OK" value="Подписаться">
Идем в шаблон компонента, находим:
<input type="submit" value="OK" name="OK" value="<?=GetMessage("subscr_form_button")?>">
Удаляем лишнее value="<?=GetMessage("subscr_form_button")?>" и у нас остается:
<input type="submit" value="OK" name="OK">
Далее смотрим- валидатор обращает наше внимание на том, что тегу <nav> не обязательно прописывать атрибут role.
Однако это не является ошибкой, поэтому не будем трогать.
Отсутствие заголовка внутри тега <section> тоже не является ошибкой, поэтому дабы не сломать шаблон, не станем лезть в него и править то, что валидатор W3C HTML5 не указал как Error.
В данном случае валидатору не понравился значок & и предлагает нам заменить его на &. Однако, если мы глянем исходный код:
<link href='http://fonts.googleapis.com/css?family=PT+Sans:400,700&subset=latin,cyrillic' rel='stylesheet' type='text/css'>
то увидим что делать нам этого никак нельзя. Поэтому просто игнорим это и идем дальше.

В этому случае валидатор ругается на атрибуты width и height для тега <a>.
Смотрим исходный код:

и понимаем что это API Твиттра и ничего мы с ним поделать не можем. Так что пропускаем.
У нас остался один не исправленный, или хотя бы не разобранный пункт — не прописан alt у очередной картинки.
Лезем в исходный код и видим что это код Яндекс.Метрики.

Ок. Сюда нам тоже лезть не с руки, ибо такой код генерирует сам Яндекс.
Вот мы и прошлись по всем ошибкам которые нам показал валидатор W3C HTML5. Что мной было уяснено в ходе написания этой статьи:
Верстка должна быть валидной уже на этапе написания шаблона сайта, ибо исправлять верстку в дальнейшем — выйдет себе дороже.

Иногда не получится выкрутиться и написать полностью валидный шаблон сайта. Некоторые теги устарели для спецификации, однако они выполняют очень важную роль для отображения элемента или контента. Или вставляя на сайт виджеты со сторонних ресурсов мы рискуем вставить код на который будет ругаться валидатор, т.к. внешний ресурс, в силу различный обстоятельств, не позаботился о том чтобы код виджета был валидным.

Для того чтобы код сайта был 100% валиден HTML5 по W3C разработчику сайта придется потратить в несколько раз больше времени, в то время как клиент не всегда готов оплачивать время затраченное на вылизывание шаблона.

Ну и на последок проверим на соответствие рекомендациям спецификации HTML5 по W3C несколько популярных сайтов:
klondike-studio.ru
Эссе о валидации данных / Habr
В заметке «Можно ли делить на 0,01 ?» на сайте тестировщиков я написал, что при тестировании нужно проверять согласованность валидаторов входных данных с логикой обработки этих данных приложением. Но из комментариев к этой заметке я понял, что для понимания того, как надо тестировать валидацию данных, надо понимать, как она должна работать, что можно считать правильным, а что нет. Поэтому я написал об этом отдельную статью. В ней рассматривается три вопроса: 1) зачем вообще нужна валидация данных, и 2) где и когда может выполняться валидация данных, 3) какие бывают разновидности проверок. Ну и конечно продемонстрировано, как всё это выглядит на живых примерах. А может быть мои рассуждения окажутся интересны не только тестировщикам, но и разработчикам.

Зачем нужна валидация данных?

Казалось бы, «невалидные» данные, не удовлетворяющие определённым ограничениям, могут вызвать сбой в работе программы. Но что это означает? Предположим, в каком-то месте программы возникает исключение при попытке преобразовать строку в число, если строка имеет некорректный формат. Разумеется, если исключение не будет нигде перехвачено, это может привести к аварийному завершению программы. Но это маловероятный сценарий развития событий. Скорее всего в каком-то месте сработает перехватчик, который либо выдаст пользователю какое-то сообщение об ошибке в программе, либо сделает запись в журнал ошибок, после чего программа постарается восстановиться от сбоя и продолжить работу. То есть даже если валидацию не выполнять, вполне вероятно, что ничего страшного не случится.
Но определённые негативные последствия у отсутствия валидации всё таки могут быть, давайте чуть подробнее рассмотрим, какие проблемы при этом могут возникнуть.
Невозможность восстановиться после сбоя. Не всегда программа способна «вернуть всё назад». Возможно, в процессе работы программа выполнила какие-то необратимые действия — удалила файл, отправила данные по сети, напечатала что-то на принтер, запустила резец станка и он частично произвёл обработку заготовки детали. Но даже если восстановление в принципе возможно, алгоритм восстановления может тоже содержать ошибки, и это иногда приводит к совсем печальным последствиям.

Дополнительная нагрузка на систему. Восстановление после сбоя — это лишняя работа. Вся работа, которая была выполнена до момента сбоя — тоже лишняя. А это означает дополнительную нагрузку на систему, которой можно избежать, если заранее проверить данные. С другой стороны, валидация — это тоже дополнительная нагрузка, причём восстановление приходится делать лишь изредка, а проверку надо выполнять каждый раз, так что ещё неизвестно, что выгоднее.

Инъекции не вызывают сбоев. Один из основных способов эксплуатации уязвимостей в программах заключается в том, чтобы «обмануть» валидаторы, то есть передать данные, которые валидатор признаёт корректными, но при этом они интерпретируются непредусмотренным образом, так что злоумышленник может получить несанкционированный доступ к данным или некоторым возможностям программы, либо способен разрушить данные или программу. Если валидации нет вообще, задача злоумышленника максимально упрощается.

Сложность идентификации причины проблемы. Если исключение вылетело откуда-то из глубины программы, определить причины его возникновения не так-то просто. И даже если это возможно, может оказаться нелегко объяснить пользователю, что сбой вызван данными, которые он ввёл некоторое время назад в каком-то совершенно другом месте программы. А если проверка выполнена немедленно после ввода данных, никаких сложностей с идентификацией источника проблемы не возникает.

Короче говоря, отсутствие валидации может приводить к вышеописанным (а может быть и ещё каким-то другим) проблемам. Соответственно, наличие валидации позволяет предотвратить серьёзные сбои, упрощает идентификацию проблем, но за это приходится расплачиваться производительностью, поскольку дополнительные проверки увеличивают нагрузку на систему. И тут мы переходим ко второму вопросу — как уменьшить эту дополнительную нагрузку.
Где и когда выполнять валидацию данных?

Как уже было сказано выше, с точки зрения уменьшения нагрузки лучше всего вообще не выполнять валидацию данных.
Но если всё-таки проверка нужна, логика подсказывает, что удобно проверять данные в том месте, где они попадают в программу из внешнего мира. После такой проверки можно быть уверенным, что в программу попадают правильные данные и в дальнейшем они могут использоваться без дополнительных проверок.Это может быть пользовательский интерфейс, через который человек вводит данные. Это может быть файл, содержащий настройки программы или данные, которые программа должна обработать. Это может быть база данных, в которую информация может попадать из других программ. Это может быть сетевой протокол обмена данными с другими программами. Наконец, это может быть программный интерфейс, который использует другая программа, вызывая некоторые функции/процедуры и передавая в них параметры.
Увы, здравый смысл иногда вынужден отступить перед натиском действительности. «Фейс-контроль» данных на входе иногда не просто нецелесообразен, но вообще невозможен. Ниже приведены некоторые причины этого.
Для валидации требуется доступ к недоступной части состояния системы. Это особенно характерно для проверки данных, вводимых человеком через графический интерфейс пользователя. Современные приложения часто построены с использованием многоуровневой архитектуры, которая предполагает, что реализация пользовательского интерфейса выделена в презентационный слой, а для проверки требуется доступ к другим слоям, вплоть до слоя базы данных.
Особенно хорошо это заметно для веб-приложений, где пользовательский интерфейс реализуется в браузере и выполняется на стороне клиента, а для проверки ввода требуется сравнение с тем, что хранится в базе данных. В этой ситуации проверку приходится выполнять уже после отправки данных на сервер. (Впрочем, сейчас с появлением AJAX-технологии эта проблема частично решена).

Валидация требует полностью повторить логику обработки. Как уже отмечено двумя абзацами выше, при многослойной архитектуре приложения пользовательский интерфейс обычно выделяется в специальный презентационный слой, а логика обработки данных находится на другом слое. И бывают такие ситуации, когда для валидации нужно практически полностью выполнить эту обработку, потому не существует более короткого способа понять, завершится она успехом или нет.

Как выполнять валидацию данных?

Впрочем, где бы ни выполнялась валидация, можно это делать несколькими различными способами, в зависимости от того, какие ограничения накладываются на данные.
Посимвольная проверка. Как правило такие проверки выполняются в пользовательском интерфейсе, по мере ввода данных. Но не только. Например, лексический анализатор компилятора тоже выявляет недопустимые символы непосредственно в процессе чтения компилируемого файла. Поэтому такие проверки можно условно назвать «лексическими».

Проверка отдельных значений. Для пользовательского интерфейса это проверка значения в отдельном поле, причём выполняться она может как по мере ввода (проверяется то неполное значение, которое введено к настоящему моменту), так и после завершения ввода, когда поле теряет фокус. Для программного интерфейса (API) это проверка одного из параметров, переданных в вызываемую процедуру. Для данных, получаемых из файла, это проверка какого-то прочитанного фрагмента файла. Такие проверки, опять-таки по аналогии с компиляторной терминологией, можно назвать «синтаксическими».

Совокупность входных значений. Можно предположить, что в программу сначала передаются какие-то данные, после чего подаётся некоторый сигнал, который инициирует их обработку. Например, пользователь ввёл данные в форму или в несколько форм (в так называемом «визарде») и наконец нажал кнопку «OK». В этот момент можно выполнить так называемые «семантические» проверки, нацеленные на валидацию не только отдельных значений, но и взаимосвязей между ними, взаимных ограничений.
Вполне возможна ситуация, когда каждое отдельное значение «синтаксически» корректно, но вместе они образуют несогласованный набор. Для программного интерфейса эта разновидность валидации предполагает проверку набора входных параметров вызываемой процедуры, для случая получения данных из файла это проверка всех прочитанных данных.

Проверка состояния системы после обработки данных. Наконец, есть последний способ, к которому можно прибегнуть, если валидацию непосредственно входных данных выполнить не удаётся — можно попытаться их обработать, но оставить возможность вернуть всё к исходному состоянию. Такой механизм часто называется транзакционным.

Транзакция — это последовательность действий, которые либо все завершаются успешно, либо происходит какой-то сбой при выполнении отдельного действия, и тогда отменяются результаты всех предыдущих действий этой цепочки. Так вот, валидацию можно выполнять в процессе выполнения транзакции, а последняя проверка может быть выполнена в самом конце транзакции по обработке данных. При этом мы валидируем уже не сами данные, а то состояние, которое получилось после их полной обработки, и если это состояние не удовлетворяет каким-то ограничениям, тогда мы признаём входные данные невалидными и возвращаем всё к исходному состоянию.
Какой способ валидации следует применять на практике в том или ином случае? Чаще всего одним способом ограничиться не удаётся, да и не нужно. Валидацию данных можно и нужно выполнять в несколько этапов, усложняя проверки.
Сначала, по мере ввода, следим за тем, чтобы данные не содержали недопустимых символов. Например, для числового поля пользователю может быть запрещён ввод нецифровых символов.
После того, как ввод завершён, можно проверить всё значение целиком. Для введённого числа могут быть какие-то ограничения, например, оно не должно превышать определённого максимального допустимого значения. Если наше числовое поле представляет собой возраст, оно должно находиться в пределах от 0 до, скажем, 120.
Когда заполнены все поля, можно проверить, согласованы ли введённые значения друг с другом. Например, если в форме кроме поля для указания возраста есть поле для ввода номера паспорта, приложение может проверить, что при заполнении номера паспорта возраст должен быть не менее 14 лет.
Наконец, если всё введено корректно, можно попытаться начать обработку, выполняя проверки по ходу дела, а также в самом конце, и если что-то пошло не так, выполнить откат к исходному состоянию.
Ну и, конечно же, проверки на следующем уровне могут подстраховывать проверки предыдущих уровней. Скажем, для веб-приложений обязательной является проверка данных, пришедших на сервер в HTTP-запросе, независимо от того, выполнялась ли перед этим предварительная валидация в браузере или нет. Причина этого в том, что проверку на клиентской стороне можно обойти. Для других видов приложений обойти проверки не так просто, но иногда тоже вполне возможно, как показано в примере чуть ниже.
Тестирование валидаторов

Завершим статью демонстрацией различных видов валидаторов, а также некоторыми рекомендациями относительно того, как при тестировании проверять правильность их работы.
Начнём с посимвольной проверки. Графический редактор Paint, диалог изменения размеров рисунка, ширина рисунка. В это поле допускается вводить только цифры, при попытке ввести другие символы выдаётся сообщение об ошибке:
Однако, проявив смекалку, можно обойти эту валидацию вводимых символов: через буфер обмена удаётся вставить в это поле отрицательное число, несмотря на то, что минус является недопустимым символом:
Впрочем, это не приводит к негативным последствиям, потому что на следующем уровне стоит ещё одна проверка, которая срабатывает при нажатии кнопки OK:
Есть и другие ограничения для этого поля, которые тоже проверяются после нажатия кнопки OK:
А вот находящееся совсем рядом в том же диалоге поле для ввода наклона рисунка не содержит валидации символов, несмотря на то, что это тоже числовое поле. Более того, при вводе недопустимых символов после нажатия OK можно увидеть вот такое странное сообщение, практически не поддающееся расшифровке:
Все вышеописанные примеры связаны с проверкой отдельно взятого поля. Пример валидации комбинации полей можно найти в том же приложении, но в другом месте — в диалоге настройки параметров страницы для печати. Если указать размеры полей страницы так, чтобы в сумме они превосходили ширину страницы, получим вот такое сообщение:
Ну и, наконец, в заметке «Почему не хватает памяти, чтобы уменьшить размеры рисунка?» описана ошибка, связанная с тем, что в этом графическом редакторе отсутствует корректная обработка сбоев и откат транзакции при слишком сильном увеличении размера рисунка.
Тестировщику необходимо все эти ситуации отрабатывать. Во-первых, нужно проверять валидацию на всех уровнях. Во-вторых, нужно проверять согласованность валидаторов на разных уровнях. В-третьих, надо искать пути обхода валидаторов, пытаясь добраться до следующего уровня без предварительных проверок.
Заключение

Большая часть этой статьи посвящена не способам тестирования валидаторов, а описанию их устройства. Почему? Потому что врага надо знать в лицо. Чтобы найти дефект валидации данных, надо понимать, где искать и на что обращать внимание.
P.S. Кросспост
habr.com
Валидатор (транспорт) — это… Что такое Валидатор (транспорт)?
Валида́тор (от англ. valid — действительный, имеющий силу, правомерный) — электронное или механическо-электронное устройство, предназначенное для отображения и/или проверки информации документов (проездных билетов общественного транспорта, пропусков) записанных на бесконтактные или контактные электронные носители для оперативного контроля за правомерностью прохода пассажира в салон автобуса, троллейбуса, трамвая и иных подобных видов наземного транспорта, на посадочную платформу в метро, на железной дороге и других видах транспорта, где контроль оплаты проезда осуществляется за пределами транспортного средства, или сотрудника в офис. Часто совмещён c турникетом.
Преимуществом валидатора служит высокая степень учёта пассажиропотока на транспорте, возможность точного контроля над посещением закрытых офисов и предприятия и сравнительно недорогая цена обслуживания устройства.

Валидаторы на транспорте
Московское метро
Московский наземный транспорт
Первые турникеты с валидаторами в наземном общественном транспорте Москвы в рамках эксперимента по внедрению автоматизированной системы контроля проезда (АСКП) появились в 2001 году в Зеленоградском административном округе на автобусном маршруте № 14^[1]. К середине 2002 года система была распространена на все зеленоградские автобусные маршруты (муниципального подчинения), а с сентября 2007 года и на весь наземный городской общественный транспорт муниципального подчинения.
Правительство Москвы мотивировало решение об установке устройств большим количеством безбилетных пассажиров, ездящим по поддельным документам.
Несмотря на то что с помощью электронной системы проверки оплаты проезда существенно сократилось число безбилетных пассажиров, многие жители Москвы отрицательно восприняли нововведение. Так, из-за автоматов посадка стала занимать больше времени: если до введения устройства посадка и высадка обычно занимала не более одной минуты, то после при большом количестве пассажиров она стала занимать 3-4 минуты. Это естественным образом отразилось на времени следования по маршруту, в некоторых случаях весьма существенно. Увеличение времени посадки привело к оттоку части платёжеспособных пассажиров в пользу маршрутных такси, которые после введения системы АСКП пережили бурный рост.
Санкт-Петербург
С января 2007 года на большинстве социальных маршрутов общественного транспорта города у кондукторов появилось устройство для считывания информации с проездных документов — валидатор. Позже валидаторы появились у водителей маршрутов, которые не имеют кондукторов.
К 2010 году кондукторов в городе не станет вовсе, а весь общественный транспорт перейдет к новейшим принципам спутниковой валидации. Стационарные валидаторы будут крепится в салоне транспорта на поручнях (от 4 до 8 штук)^[2]^[3].
Эта система постепенно уже начала внедрятся на маршрутах петербургского наземного транспорта^[4]^[5].
Другие города
На текущий (ноябрь 2007-го) момент существуют планы введения валидаторов на общественном транспорте Московской области.
В городе Алма-Ата (Казахстан) с января 2008 года система оплаты проезда через валидатор с помощью электронной карты или наличными действует во всех трамваях и троллейбусах города. В автобусах данная система проходит испытание, планируется запустить валидаторы на автобусах с конца января 2009 года.
Ссылки
Примечания
Wikimedia Foundation. 2010.
dic.academic.ru